Computer based system for supporting a work process in which some tasks require participation of multiple persons in differentiated roles

ABSTRACT

A computer-based method and apparatus for the analysis, specification and support of work processes. The system is designed to support multiple interdependent decisions, at least some of which require collaboration among multiple participants ( 116 ). Work processes are modeled using an application framework ( 99 ) used to develop abstract, decision ( 100 ) process models. The decision ( 100 ) process models are used as a pattern to instantiate concrete process models that incorporate the work defined by the abstract process. The process model is then used to instantiate project models that incorporate the required work from the process. The project models are used to direct and guide the behavior of the participants ( 116 ) in the work process.

FIELD OF THE INVENTION

The present invention pertains to the field of computer-supportedcollaborative work. More specifically it presents a method and apparatusfor (1) analyzing the requirements of such work, (2) specifying theprocess by which such work shall be carried out, (3) instantiating workprojects based upon the specified process pattern and (4) implementingcomputer-based systems to support the execution, control, andimprovement of such collaborative work.

BACKGROUND OF THE INVENTION

“Best practice” in accounting, financial transaction processing, orderprocessing, inventory management, and purchasing has benefitted greatlyfrom, and is heavily dependent on, the use of information technology.Although desktop computers have become ubiquitous in other areas ofbusiness such as, engineering, marketing, sales and general management,the benefits have been far more modest. In these areas of largelyprofessional and managerial work, computers have been used extensivelyto support the work of individuals. But information technology has beenmore difficult to exploit in professional and managerial work thatrequires significant collaboration among individuals. Three generalapproaches have been taken to leverage technology in the service ofmanagerial and professional work—workgroup software, workflow software,and decision support software.

Workgroup software focuses on the need for communication among the manyparticipants in managerial and professional work processes. It can beused to breach the organizational boundaries, both within and amongorganizations, and is adaptable to almost any set of organizationalcircumstances. Such flexibility can be advantageous when therequirements for communication are poorly understood or constantlychanging. However, there are costs incurred for such flexibility. Theadministration and operation of such applications may become quitecomplex. Furthermore, it is sometimes advantageous to restrict the formsthat a process may take to achieve not only greater economy butincreased repeatability and reliability.

Workflow software is grounded in the paper metaphor of document routing.It should be economical in its use of resources and provide highrepeatability due to a more restrictive, and therefore more definitive,structure than workgroup software. However, workflow software is bettersuited to clerical, document processing activities than to managerialand professional work. In contrast to clerical activities in which mostdecision situations are well understood and can be made by a singleindividual, managerial and professional work often entails decisions inwhich a number of people need to collaborate. This essential need forcollaboration is the root of the ever present meetings that managers andprofessionals everywhere bemoan.

Early decision support software used information technology to supportindividual decision makers with data retrieval and data manipulationcapabilities that could significantly enhance the quality of theirdecisions. Recent efforts have expanded decision support for individualdecisions to group settings. However, decision support software does notattempt to structure the roles played in the decision by variousindividuals, nor does it usually structure the interdependencies of morethan a few closely related decisions.

Professional And Managerial Work Processes.

Professional and managerial work processes characteristically result,not in products made of wood, steel or plastic, but products that arecomposed predominately or even entirely of data. Business plans, productspecifications, labels, advertisements, computer software, consultingreports, purchase orders, quotations, requests for quotation, andpublications of all sorts, are typical products of managerial andprofessional work processes.

The data assemblies that are produced by managerial and professionalwork processes, like their physical counterparts, are sometimes built upin stages as sub-assemblies (e.g., the nutritional content section ofthe food package label, the terms and conditions section of the productquotation). This tiered structure is illustrated by FIG. 1, and moregenerally and succinctly by FIG. 2.

Each data element, whether elementary, a sub assembly or final assembly,is the product of a decision. That is, it is selected from two or morealternatives. For example, the color specified in a productspecification might be red, green, or blue. The business plan thatincludes a $3 million advertising budget could have instead, includedone for $2.5 or $2 million. Or it could have included separate lineitems for advertising by geographic region, or by type of media, or byproduct line, or various combinations of these possibilities. What itdoes contain is a matter of choice (i.e, a decision) and results indata.

The data assemblies that result from managerial and professional workprocesses are the product of numerous decisions. More importantly, manyof these decisions are logically, and therefore temporally ordered. Justas we cannot assemble a computer before we produce its subassemblies,nor its subassemblies before the components it contains, neither can weassemble a business plan or a quotation before we make the decisionsthat produce the data from which it is assembled. There's a logicalrequirement that the components exist before the assembly.

In the physical work of manufacturing, there are also temporalprecedence requirements that involve the transformation of materials,rather than the assembly of components. Raw material must be reduced topower or a molten state before it can be cast. And it must be castbefore it can be machined. Analogously, in managerial and professionalwork processes data is sometimes required as the raw material for adecision even though it doesn't show up as a component of thatdecision's result. For example, the decision to label a product either“corrosive” or “non-corrosive” may require a prior determination of theproduct's pH. The pH is raw material that is processed, perhaps withother data, by the “Corrosive?” decision, but does not become acomponent of the result of the “Corrosive?” decision. Similarly, thenumber of households owning fewer than two television sets may be datathat is required for the “Market Potential?” decision, but it is notassembled into that decision. However, both the market potential numberand the number of households owning fewer than two TV's would probablybe components of the assembly, “Product Marketing Plan”.

Need for Participation in Decision-Making. For a number of years therehas been widespread recognition that it is desirable to get more peopleinvolved in important organizational decisions. The decisions made andactions taken in a complex organization composed of interdependent unitsfrequently require contributions and commitments from many individualsif they are to succeed. Although this may seem a recent phenomenon, theinterdependence and complexity were always there. In the past mostpeople were not aware of it, nor did they need to be. Organizationsignored much of the complexity and used extra resources (e.g., people,inventories, equipment, time, etc.) to decouple the interdependencies.

But as progressive organizations began to use information technology toreduce the slack in their organizations and to increase their ability todeal with complexity, they gained competitive advantage. Others have hadto follow or perish. In most businesses the elimination of slackresources has exposed inadequacies in the organizational infrastructure.The inability to adequately integrate and coordinate decision-makingacross tightly coupled organizational layers and functions is often aproblem.

Involving others in decision-making is a way of integrating andcoordinating complex organizational activity. The advantages of a moreparticipative decision process include not only better decisions becauseof better information, but more readily implementable decisions becauseof the commitment of the participants to carry it out. Nevertheless, theresults from involving more people in decision-making have frequentlybeen disappointing at best and a frustrating waste of time at worst. Inthe '70's, “participative management” was espoused by academics,promoted by consultants, and loudly proclaimed by many managements. Thedisappointment, if not disillusionment that followed, was of coursepredictable. It was yet another case of a very valid and useful ideathat was over-promoted and under-invested.

In the '80's “participative management” was superseded by the coming of“teams” with similar results. It is often at least useful, and perhapsessential, for a group of people to work together interactively—as ateam. It is seldom adequate however, to roundup a group, anoint themwith “teamhood,” provide team T-shirts and send them off to play thegame. The football, basketball, and other teams that provide the modelfor organizational teams, don't usually play the game withoutconsiderable investment in learning how to “block and tackle” and thenpracticing the “blocking and tackling” repeatedly until they do itreally well. They also develop “play books” and shared understanding ofcryptic signals, They learn to anticipate each others moves, again as aresult of much practice together. Where are the organizationalequivalents of these indispensable requirements for the success ofathletic teams? What one usually finds is a one day, or at most one weekcourse, followed be a return to the workplace bearing an appropriatelyemblazoned coffee mug and plaque for the wall.

Participative decision-making was and is a good idea. However, it is anidea that contains several traps for the unwary. A common trap is theassumption (usually unexamined and unstated) that participation meansequality-that everyone who participates, participates in the same wayand to the same degree. From that assumption flows the furtherassumption that everyone gets a vote, that the majority rules or thatunanimity or consensus must be achieved if a decision is to be made.While there may be situations where such assumptions are appropriate, inmost organizational situations they are neither desirable nor realistic.

A critical omission from many organizational teams is an appropriate setof clearly differentiated roles for the players and a relatedvocabulary. The “players” need a way to communicate effectively with oneanother about the “positions” they are playing, the “moves” they intendto make, and what they expect of their colleagues.

We need a method to analyze, specify and support work processes thatconsist of many, interdependent decisions, at least some of whichrequire collaboration among multiple participants for satisfactoryresults. This is at least part of an answer to two critical problemscurrently faced by most complex organizations—1) How to get betterintegration of effort across organizational boundaries, both thosecreated within organizations (e.g., between engineering andmanufacturing, or eastern sales region and central sales region) and theboundaries between organizations (e.g., customer and supplier, businessand government, federal government and state government), and 2) How toimprove the performance of managerial and professional work, where suchperformance may be measured in terms of reliability of the process inproducing quality output, the productivity of the process, or the speedof the process

SUMMARY OF THE INVENTION

The present invention provides a novel way of using informationtechnology in support of professional and managerial work processes. Theapproach is based on the modeling of professional and managerial workprocesses as networks of multiple, interdependent decisions, some ofwhich may involve multiple participants in specific, differentiatedroles. The proposed method entails the modeling of the work processusing several familiar entities—decisions, decision rules and data—andanother less familiar set of entities—decision roles. The work processmodel produced using these entities is used as a pattern for thegeneration of project models. These project models are a central elementin a computer- and communications-based infrastructure to direct andguide the behavior of the participants in the work process.

Like both workflow and workgroup software, this approach recognizes theimportance of facilitating communication among collaboratingindividuals. Like decision support software, this approach recognizesthe utility of assisting workers with access to appropriate data and themanipulation of that data. Unlike other approaches the proposed approachprovides a method for structuring professional and managerial processesmodularly using object technology and with a degree of structure thatcan be varied for each object independently. When understanding of thework process is great, that knowledge can be used to build more highlystructured, and therefore more valuable, supporting infrastructure.Where less precise or less fully defined understanding of the workprocess is all that is available, the proposed method allows acorrespondingly less structured supporting infrastructure that can beenhanced as understanding of the process increases.

The exploitation of information technology in support of professionaland managerial work has been limited by failure to specify the processesused to accomplish such work. The available tools for modeling andspecifying such work have been inadequate. The present invention isbased on a methodology that addresses this inadequacy. Professional andmanagerial work processes are modeled as networks of linked decisionsand data. The decisions that make up such work often require significantparticipation of many people. The approach utilized by the presentinvention identifies the roles that are useful and providesspecifications for the behavior and requirements of individuals playingthose roles.

Decision Networks. Every decision produces a result in the form of data.Although any decision may be viewed in isolation, it is useful toidentify the data required to make the decision. That data is in turnthe result of one or more other decisions. Therefore, the decision thatrequires data is dependent on the decisions that produce it (See FIG.3). Therefore, if we establish the interdependencies among decisionsbased on our understanding of the data they produce and the data theyrequire, we have established a basis for both routing data andtriggering decision situations. That is, send a data element to alldecisions requiring it, and trigger a decision when all required datahas been received.

Each decision is viewed as an “atomic” process-taking required data andprocessing it to produce a result as output data. The decisions thatmake up professional and managerial work processes are typically relatedto other decisions by virtue of their need for data resulting fromearlier decisions. FIG. 4 depicts a typical decision process, in thiscase a proposal preparation process for some equipment. The nodes of thenetwork are the decisions with their associated data output. Thedecision interdependencies are depicted as directed arcs connecting thenodes. The connecting arcs run from the independent decision at theentry of the arc to the dependent decision at the exit end of the arcwhich is indicated by an arrowhead. Professional and managerial workprocesses are treated therefore, as “molecular” networks of such“atomic” decision processes that convert data to a desired output. Themethod of the present invention couples these decision networks to astructure for participation by multiple individuals in the “atomic”decision processes.

Decision Roles & Responsibilities. A structure is needed for successfulparticipative decision-making that explicitly recognizes the differentreasons for participation and the different capacities in whichparticipants can be expected to contribute. It has proven useful todistinguish five decision roles, namely: Decision Manager, Consultee,Approver, Inspector, and Informee.

The Decision Manager plays the central role that has traditionally beenassociated with the term “decision maker,” that is, making the choice ofone from among two or more possible options. However, the role alsocarries critical additional responsibilities. The Decision Manager mustmanage the decision process and take responsibility for implementationof the decision. Our paradigm of the “decision maker” has beenprofoundly influenced by our experience of decision-making as asolitary, rather than a group process. The term “Decision Manager” hasbeen deliberately chosen here to help break the paradigm's hold on ourthinking—to emphasize responsibility for the conduct of the decisionprocess rather than for the mere selection of an alternative. Thedecision maker has usually been associated only with the latterresponsibility. Our Decision Manager is responsible for both the choiceand the process of choosing.

The role of a Consultee is to provide either expertise required to makea good decision or commitment of resources needed for successfulimplementation. A Consultee has a right to the opportunity to influencethe Decision Manager's choice, not a right to veto that choice. Theconsultation process, which is managed by the Decision Manager, may takeany of several forms at the discretion of the Decision Manager. Indecision situations that require more than two or three Consultees orthat are new, unclear or complex, the Decision Manager may find itappropriate to bring the Consultees together for one or moreface-to-face meetings. This differs from common practice only in havingmore thoughtfully selected attendees, more explicit delineation anddefinition of attendee roles, and a more precisely focused agenda.Usually, where the number of Consultees is few, or the decision straightforward, face-to-face meetings are probably unnecessary. Instead, theDecision Manager may hold a tele-conference, or she may simply solicitparticipation from the Consultees individually by any means ofcommunication available, with or without some preliminary indication ofthe decision result that she has in mind. The only requirement is thatthe Consultees feel that they have had an adequate opportunity toinfluence the Decision Manager's choice.

An Approver's role is to prevent organizationally intolerable outcomesthat might result from a decision made without the benefit of someexpertise that the Approver has, and is not otherwise available to theDecision Manager. The other reason for an Approver is to assure that thedecision has not been unduly influenced by the parochial interests ofthe Decision Manager to the detriment of the organization. The Approverrole is like the Consultee role with two important differences. TheApprover has veto power (i.e., he must be satisfied with the decisionresult and the process) and the Approver does not participate fully inthe deliberations that take place before the decision. It is desirablefor the Approver to be informed about the progress and content oflengthy and complex deliberations as they go on, rather than beinginformed at the conclusion. However, the Approver's full participationin the pre-decision deliberations would severely undermine the role ofthe Decision Manager, since the Approver would essentially be taking onthe role of Decision Manager. (It would be better to make the DecisionManager a Consultee and make the Approver the DecisionManager—explicitly.)

An Informee's role is to make subsequent decisions and performsubsequent tasks in a way that is consistent with the decision made. Thedefining characteristic of this role is that, while an Informee'sparticipation in the deliberations leading up to the decision is notuseful, his or her failure to participate in carrying out the decisionmay seriously undermine the implementation. Consider, for example, thepayroll clerk. In most organizations it would not be useful to includethe payroll clerk in decisions regarding the size of salaries andbonuses to be awarded. But failure to inform the clerk of the decisiononce it has been made, renders the decision moot.

The Inspector's role is to ensure that the result of a decision conformsto any published specifications. Individuals who are called “approvers”are often merely inspectors. These so-called “approvers” are checking tosee that others have done what they were supposed to have done—that is,they are checking to see that the result of the decision conforms tosome set of specifications. For example, a lawyer may check to see thatthe copyright and trademark notices have been properly displayed. Amarketing manager may verify that the artist has used the correctcolors. This is a different role than the one we have outlined above inthat the requirements are fully established and the so-called “approver”is simply checking to see that they have been met. Unlike the Approver'srole, these tasks could be delegated to any conscientious person. Thisis an inspector's job and we therefor call the role “Inspector.”

The five decision roles and their specific responsibilities to othersare set forth in Table A.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings, the preferred embodiment of the inventionand preferred methods of practicing the invention are illustrated inwhich:

FIG. 1 is an object diagram illustrating a prototypical aggregation ofdata.

FIG. 2 is an object diagram defining the general aggregation of data.

FIG. 3 is a schematic diagram illustrating the relationship of data todecisions and the linking of decisions through data.

FIG. 4 is a schematic diagram illustrating the network structure ofdecisions in a typical decision process—in this instance a hypotheticalproposal preparation process.

FIG. 5 is a class diagram illustrating the abstract and concrete classescomprising the application framework of the present invention.

FIG. 6 is a class diagram illustrating the relationship between two ofthe abstract classes, Decision and Data, of the application frameworkand their concrete classes and object instances.

FIG. 7 is a class diagram depicting the classes and objects comprising aprototypical process model generated with the application framework ofthe present invention (reference made to FIG. 4).

FIG. 8 is a class diagram depicting the classes and objects comprising aprototypical project model instantiated by the prototypical processmodel of FIG. 7.

FIG. 9 is a class diagram depicting the classes of the applicationframework of the present invention and their relationships to oneanother.

FIG. 10 is state diagram depicting the aspects of the Project objectthat change over time.

FIG. 11 is state diagram depicting the aspects of the Decision objectthat change over time.

FIG. 12 is state diagram depicting the aspects of the Data object thatchange over time.

FIG. 13 is state diagram depicting the aspects of the Directed Arcobject that change over time.

FIG. 14 is state diagram depicting the aspects of the Arc EntryCollection object that change over time.

FIG. 15 is state diagram depicting the aspects of the Arc ExitCollection object that change over time.

FIG. 16 is state diagram depicting the aspects of the Decision Managerobject that change over time.

FIG. 17 is state diagram depicting the aspects of the Consultee objectthat change over time.

FIG. 18 is state diagram depicting the aspects of the Inspector objectthat change over time.

FIG. 19 is state diagram depicting the aspects of the Approver objectthat change over time.

FIG. 20 is state diagram depicting the aspects of the Informee objectthat change over time.

FIG. 21 is a data flow diagram depicting the data flow and valuetransformations required to instantiate a Project object and theDecision, Directed Arc and Arc Collection objects of the Project.

FIG. 22 is a data flow diagram depicting the data flow and valuetransformations required to instantiate Decision Role objects.

FIG. 23 is a data flow diagram depicting the data flow and valuetransformations required to instantiate Data objects.

FIG. 24 is a data flow diagram depicting the data flow and valuetransformations required to iterate a Project object.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Glossary. The discussion of the present invention utilizes certain termsin a precise sense. The following definitions of those terms areprovided for clarity.

“Decision” means a decision situation in which a choice is to be madefrom among two or more alternatives (e.g., color?, corrosive?, price?,supplier? quantity?). The number of alternatives may be infinite orunknown.

“Data” means the result of the act of deciding (e.g., red, yes, $5.00each, Acme, 650). A data element may be divisible into constituent dataelements (e.g., cells in a matrix, items in a list, characters in astring, delimited areas of a graphic).

37 Decision Role” means the set of behaviors prescribed for aparticipant in a decision (e.g., Decision Manager, Consultee, Approver,Inspector, Informee). There can be any number of different roles definedfor participants.

“Position” means position or job in an organization, usually designatedby a title (e.g., President, CEO, Quality Manager, Foreman, Chemist) andjob description.

“Process” means a system that converts inputs to outputs (e.g., computersystem, manufacturing system, water purification system, justicesystem).

“Decision Process” means a process whose inputs and outputs are data, orartifacts containing data (e.g., business planning process, productdevelopment process, sales process, customer support process), and whoseprincipal components are decisions.

“Process Model” means a model constructed of both concrete and abstractclasses and object instances of some of those classes, that specifiesand defines the way in which the work of a decision process will beperformed.

“Project” is an instance of a process model (e.g., this year's businessplan, the development of an improved widget, getting the Acme Companyorder, addressing the issues at Consolidated Corp.).

Terms of Art. The invention has been developed and is presented hereusing the conventions and practices of Object Modeling Technique (OMT).

A class is an abstraction that describes properties important to anapplication and ignores the rest. —Each class describes a possiblyinfinite set of individual objects. Each object is said to be aninstance of its class. (James Raumbaugh, Michael Blaha, Williampremerlani, Frederick Eddy, and William Lorensen, Object-OrientedModeling and Design, Prentice Hall: Englewood Cliffs, N.J., 1991, p. 2)

An abstract class is a class that has no direct instances but whosedescendent classes have direct instances. A concrete class is a classthat is instantiable; that is it can have direct instances. (ibid., p.61)

The OMT methodology uses three kinds of models to describe a system: theobject model, describing the objects in the system and theirrelationships; the dynamic model, describing the interactions amongobjects in the system; and the functional model, describing the datatransformations of the system. Each model is applicable during allstages of development and acquires implementation detail as developmentprogresses. A complete description of a system requires all threemodels.

The object model describes the static structure of the objects in asystem and their relationships. The object model contains objectdiagrams. An object diagram is a graph whose nodes are object classesand whose arcs are relationships among classes.

The dynamic model describes the aspects of a system that change overtime. The dynamic model is used to specify and implement the controlaspects of a system. The dynamic model contains state diagrams. A statediagram is a graph whose nodes are states and whose arcs arc transitionsbetween states caused by events.

The functional model describes the data value transformations within asystem. The functional model contains data flow diagrams. A data flowdiagram represents a computation. A data flow diagram is a graph whosenodes are processes and whose arcs are data flows.

The three models are orthogonal parts of the description of a completesystem and are cross-linked. The object model is most fundamentalhowever, because it is necessary to describe what is changing ortransforming before describing when or how it changes.

Object-oriented development places a greater emphasis on data structureand a lesser emphasis on procedure structure than traditionalfunctional—decomposition methodologies. —[It] adds [and relies on] theconcept of class-dependent behavior. (ibid., pp. 6-7)

Abstract classes form the basis of a framework. If abstract classesfactor out enough common behavior, other components, that is, concreteclasses or other abstract classes, can be implemented based on thecontracts offered by the abstract classes. A set of such abstract andconcrete classes is called a framework.

The term application framework is used if this set of abstract andconcrete classes comprises a generic software system for an applicationdomain. Applications based on such an application framework are built bycustomizing its abstract and concrete classes. In general, a givenframework anticipates much of a software systems's design. The design isreused by all software systems built with the framework. (Wolfgang Pree,Design Patterns for Object-Oriented Software Development,Addison-Wesley: Reading, Mass., 1995, p. 54.)

Conventions. References in the description to specific elements offigures are keyed with numerals that appear bold-faced in both the textand the figure. Numeric references to classes and their objects arenumerals below 200 and are consistent across all figures. All othernumeric references are specific to the particular figure. Notation usedin figures is generally that of OMT (Rumbaugh, et.al., op. cit., insidefront & back covers.). Class, object and state names are capitalized.Abstract class names are also italicized and underscored in figures, butnot in the text. A question mark, “?”, at the end of a class name isused to distinguish a concrete decision class or object name from theirrelated concrete data class or object names.

Framework Architecture. The present invention consists of an applicationframework for the development of abstract, decision process models. Eachsuch decision process model is used as a pattern to instantiate concreteproject models that incorporate the work defined by the abstractprocess. The framework is built around a core set postulates—1) the workof the process requires the production of data or artifactsincorporating data, 2) decisions are the processes that produce data, 3)some decisions themselves require data, either as raw material which isprocessed or as a component of a data assembly, 4) some decisionsrequire the participation of two or more persons in differentiatedroles, 5) a process model specifies how work shall be done, 6) a projectis a unit of work performed in accordance with the process, and 7)decisions that require data are logically, and therefore temporallydependent on the decisions that provide the required data.

Object Model

The Framework 99 is constructed from a related set of abstract andconcrete object classes that are depicted in FIG. 6. The abstractDecision class 100 has members that are classes of decisions which arespecific to the application domain. In the example, depicted in FIG. 4,all of the boxes representing nodes of the network would be modeled asconcrete class instances of the Decision class 100. This relationshipbetween the abstract Decision class 100 and some of it's concreteclasses and object instances are more clearly depicted in the upper halfof FIG. 6. The Data class 101 is also an abstract class that has aone-to-one relationship with the Decision class 100. The relationshipbetween the abstract Data class 101, its concrete classes and theirobject instances is shown in the lower half of FIG. 6. Referring againto FIG. 5, the other abstract classes of the Framework 99 are ArcCollection 115 and Decision Role 121. The Arc Collection class 115 hastwo concrete subclasses, Arc Entry Collection 134 and Arc ExitCollection 136. The instances of these classes are collections ofDirected Arc 107 objects which are instances of another one of theFramework's 99 classes. These two subclasses are differentiated by theend of the Directed Arc 107 object that they use to determine theirmembers; the former using the entry end of the Directed Arc 107 object(the end without the arrowhead in FIG. 4) and the latter using the exitend. The abstract Decision Role class 121 has five concrete classes inthe preferred implementation, Decision Manager 142, Consultee 143,Approver 144, Inspector 145, and Informee 146. These four concrete,subclasses model the behaviors and responsibilities described in TableA. As indicated in FIG. 5, there will be exactly one Decision Manager142 related to each Decision 100. There may or may not be any Position119 designated to participate 120 in a Decision 100 in any of the otherfour roles 143, 144, 145, and 146. Nor is there a limit on the number ofPositions 119 that may participate 120 in any of these latter fourroles. The final classes of the Framework 99 are the concrete classesPosition 119 and Person 116 which model the organization and theincumbents of the organization respectively.

The Framework 99 depicted in FIG. 5 has both abstract and concreteclasses but no objects. Two of its abstract classes do not have anyconcrete classes. FIG. 7 depicts classes and objects of a hypotheticalProcess Model 129 derived from the Framework and based on the exampledepicted in FIG. 4. In addition to the elements of the Frameworkdepicted in FIG. 5, the Process Model 129 has concrete subclasses Cost10, Price 11, Terms 12 etc. of the of the abstract Data class 101, andconcrete subclasses Cost ? 14, Price ? 15, Terms ? 16 etc. of the of theabstract Decision class 100. ( the short broken lines 13 and 17 indicatethat there are other concrete subclasses of these two abstract classeswhich have been omitted for clarity.) The Framework 99 abstracts thedesired behavior common to all decision processes whether they be aproposal preparation process, a product development process, or astrategic planning process. The Process Model 129 is more concrete andspecific. It abstract only those desired behaviors that are common tothe particular decision process being modeled, in the exampleillustrated in FIG. 4, FIG. 6, and FIG. 7, the proposal preparationprocess of the organization or organizations that use this particularprocess. The Process Model 129 also includes the objects which areinstances of the concrete classes Directed Arc 107, Arc Entry Collection134, Arc Exit Collection 136, Position 119, and the five concretesubclasses of the Decision Role class 121 to the extent that any arespecified for this particular process.

The only potential objects that are missing from the Process Model 129are the objects that are instances of the concrete subclasses ofDecision 100 and Data 101 and the concrete class Person 116. Unlike theobjects that are included in the Process Model 129, the missing objectsare expected to change from project to project as the process isfollowed. These are the objects that belong to the Project Model 127 andare so depicted in FIG. 8 (see 23, 24 and 25).

FIG. 9 depicts the classes of the Framework 99 with all of theirimportant associations, some of which were omitted from the foregoingfigures and discussion. As illustrated in FIG. 9, each instance of theDecision class 100 produces 102 one, and only one, instance of theconcrete subclasses of Data class 101. The instances of Data 101'sconcrete classes, may be of any type including two-valued boolean,simple scalars, text strings or more complex types such as matrices,graphics or documents. Data 101 is also related to Decisions 100 inanother way. A Decision 100 may require 103 one or more elements ofrequired Data 104 as input. A Decision 100 in such a relationship withrequired Data 104, is a requiring Decision 105. For example, the “quotedprice?” Decision 100 may require 103 the required Data 104, “quantityquoted”, which is produced 102 by the “quantity to quote?” Decision 100.The “quoted price?” Decision 100 might also require Data 104 from the“customer class?”, “delivery requirement?”, “terms quoted?”, and“competitive situation?” Decisions 100.

Each element of required Data 104 has 106 one or more Directed Arcs 107which are paired 132 one-to-one with the required by 103 relationshipbetween each element of required Data 104 and each of the requiringDecisions 105. Each Directed Arc 107 is related at its exit 108 end tothe requiring Decision 105 of the related 106 required Data 104. At itsentry 109 end, each Directed Arc 107 is related to the producingDecision 110 of the required Data 104 associated 106 with the DirectedArc 107.

Requiring 105 Decisions 100 and their dependencies upon producing 110Decisions 100 are connected by Directed Arcs 107 with an entry at theend of the arc connected to its respective producing 110 Decision 100and an exit at the end of the arc connected to its requiring 105Decision 100. Each Directed Arc 107 ia a member 133 of one Arc EntryCollection 134 comprised of 133 all and only those Directed Arcs 107which have the same producing Decision 110. Each Directed Arc 107 iaalso a member 135 of one Arc Exit Collection 136 comprised of 135 alland only those Directed Arcs 107 which have the same requiring Decision105. Arc Entry Collections 134 and Arc Exit Collections 136 arespecializations of the Arc Collection 115 class, which specialization isbased on whether the class is defined by its entry 109 relationship orits exit 108 relationship.

Persons 116 occupy 118 organizational Positions 119 which participate120 in Decisions 100 in a Decision Role 121 that defines the expectedand acceptable behaviors associated with that participation 120.

A subset 122 of required Data 104 may be used as Rules 123. Such Rules123 may be used to make 124 Decisions 100. For example, a rule formaking a Decision that converts “quantity quoted” and “list price” into“price quoted” might be “IF {quantity quoted}<10, THEN {pricequoted}={list price}, ELSE {price quoted}=0.9*{list price}.” A Rule 123may also be used to specify the applicability 125 of a Decision Role121, or both 126 of an element of required Data 104 and 127 itsassociated 106 Directed Arc 107. Note that the Rule 123 determining theapplicability of required Data 104 and the Rule 123 determining theapplicability of its associated 106 Directed Arc 107 is constrained tobe the same Rule 128 because required Data 104 and its associated 106Directed Arc 107 must be either both applicable, or both inapplicable.Note also, that a Rule 123 may be used to specify the applicability 126of another Rule 123, since that other Rule 123 is also an element ofrequired Data 104. Examples of these uses of rules to governapplicability are:

-   -   (1) Decision Role 121 applicability 125: “IF {product        category}={lawn care}, THEN {Decision Manger}={Product Manager,        Lawn Care}, ELSE IF {product category}={snow blowers}, THEN        {Decision Manger}={Product Manager, Snow Handling}, ELSE        {Decision Manger}={Marketing Manager};”    -   (2) Directed Arc 107 and required Data 104 applicability 126 and        127, where required data does not operate as a rule: “IF        {product's ‘kill claims’}={none}, THEN {registration number} NOT        REQUIRED by {label layout} AND Arc: {registration number} to        {label layout} NOT APPLICABLE, ELSE; {registration number}        REQUIRED by {label layout} AND Arc: {registration number} to        {label layout} APPLICABLE;    -   (3) Directed Arc 107 and required Data 104 applicability 126 and        127, where required data does operate as a rule: “IF {product        status}={established}, THEN use {quantity discount rule}, ELSE,        use {null rule}.”

All of the foregoing object classes other than Project 127 aggregate toProcess 129, which is managed 117 by a Person 116 occupying 118 aPosition 119 which has been designated the “Process Manager.”Alternatively, a Person 116 could be directly designated to manage 117 aProcess 129 without an intervening Position 119. A Project 127 isinstantiated 128 based on the pattern provided by the Process Model 129and a related initial 130 Decision 100. The Project 127 network consistsof an instance of the initial 130 Decision 100, together with aninstance of each of the decisions in the Process 129 that require 103,directly or indirectly, the data 104 produced by 102 the initial 130Decision, and an instance of all the Directed Arcs 107 connecting theinitial 130 Decision 100 and the directly and indirectly requiring 105Decisions 100. A Project 127 is managed 131 by a Person 116 designatedthe “Project Manager”. Alternatively, a Person 116 could be designatedto manage 131 a Project 127 via an intervening Position 119, as isindicated for management 117 of Process 129.

Dynamic Model

Dynamic Behavior of Project 127 Object. The dynamic behavior of theProject 127 object is depicted in FIG. 10. The Project 127 object isinstantiated in Active 451 state. If a project is put on hold theProject 127 object transits 452 to Suspended 453 state. Upon releasefrom project hold the Project 127 object transits back to Active 451state. If the project receives a pause 455 the Project 127 objecttransits 455 to Paused 456 state. Upon resume 457 the Project 127 objectreturns 457 to Active 451 state. If the project is aborted from any ofits three states the Project 127 object transits 458, 459, or 460 out ofexistence.

Dynamic Behavior of Decision 100 Object. The objects of thedomain-specific, concrete classes generated from the abstract Decision100 class are the central controlling actors of the “atomic”,intra-decision process. Referring to FIG. 11, upon its instantiation 200as a component of the a Project 127, a Decision 100 object is in Dormant201 state. It remains in Dormant 201 state until activated by the ArcExit Collection 136 related to it. When so activated, a Decision 100object transits 202 to Decision Release Pending 203 state. From DecisionRelease Pending 203 state, a Decision 100 object transits 204 to PrepareConsultation 205 state upon “release” if the number of Consultees 143designated for the Decision 100 object is greater than zero. If thenumber of Consultees 143 is zero, it transits to Deliberation 210 state,upon release. “Release” is the default value of a Decision 100 object'sRelease/Hold attribute. It can be toggled between “release” and “hold”by any authorized individual (most appropriately, the Project Manager)at any time that the Decision 100 object is in Decision Release Pending203 or Dormant 201 states. If the Release attribute is toggled to“release” while the Decision 100 object is in Decision Release Pending203 state, the object immediately transits 204 or 209 to either PrepareConsultation 205 state or Deliberation 210 state depending upon whetherit does or does not have Consultees 143 designated. Upon exitingDecision Release Pending 203 for the first time, a Decision 100 objectcauses the instantiation of all its designated Decision Role 121objects.

When in Prepare Consultation 205 state and the Decision Manager 142 isprepared to begin consultation with the designated Consultees 143, theDecision Manager 142 initiates the Decision 100 object's transit 206 toConsultation 207 state. Transit 206 causes notification to be sent toall designated Consultees 143, that Consultation 207 on this Decision100 object has begun. When the Decision Manager 142 determines that therequirements for consultation have been satisfied, the Decision 100object transits 208 to Deliberation 210 state, causing notification ofall Consultees 143. When the Decision Manager 142 enters the decisionresult, the Decision 100 object either transits 211 to Inspection 214state, or transits 213 to Approval 215 state, or transits 212 to Standby216 state, depending on whether the Decision 100 object has at least oneInspector 145 designated, or no Inspectors 145, but at least oneApprover 144, or neither Inspectors 145 nor Approvers 144, respectively.From the Inspection 214 state, the Decision 100 object either transits219 to Approval 215 state, or transits 220 to Standby 216 state when theresult of inspection is “pass” and the Decision 100 object has,respectively, at least one Approver 144 or no Approvers 144 designated.When the result of the inspection is “fail,” the Decision 100 object inInspection 214 state either transits 217 to Prepare Consultation 205state or transits 218 to Deliberation 210 state, depending on whetherthe Decision 100 object does or does not have any Consultees 143designated. When a Decision 100 object is in Approval 215 state and theresult is “deny,” it either transits 222 to Prepare Consultation 205state or transits 223 to Deliberation 210 state, depending upon whetherthe Decision 100 object does or does not have any Consultees 143designated. If the result in Approval 215 state is “grant,” the Decision100 object transits 221 to Standby 216 state. Upon completion of aProject 127, all of the Project's Decision 100 objects will be inStandby 216 state and will transit 230 out of existence.

The states Prepare Consultation 205, Consultation 207, Deliberation 210,Inspection 214, Standby 216, and Approval 215 of a Decision 100 objectaggregate to state InProcess 224. While a Decision 100 object is inInProcess 224 state, it may become necessary to reconsider, andtherefore to iterate the Decision 100 object's decision process from itsinitial state. Therefore, such iteration causes a Decision 100 object inInProcess 224 state to transit 225 to Dormant 201 state, or if inDecision Release Pending 203 state, to transit 226 to Dormant 201 state.If the Project 127 of which the Decision 100 object is a part, isaborted while in any state, the Decision 100 object transits 227, 228,or 229 to out of existence.

Dynamic Behavior of Data 101 Object. Each Decision 100 object isassociated one-to-one with the Data 101 object it produces 102. Thedynamic behavior of Data 101 objects is depicted in FIG. 12. A Data 101object is instantiated 240 in state Entry Pending 241 when the DecisionManager 142 of its producing 110 Decision 100 is ready to enter thedecision result. Upon completion of the decision entry , the Data 101object transits 243 to Inspection or Approval 245 state if there is atleast one Inspector 145 or one Approver 144 designated for the Decision100. Otherwise, upon decision entry the Data 101 object in Entry Pending241 state transits 244 to Data Release Pending 246 state. Wheninspection results have been entered by all Inspectors 145 designatedfor Decision 100, the inspection results are evaluated. If any suchresult indicates “fail,” the Data 101 object's state transits 248 toHistorical 249 state. If all inspections result in “pass,” and there areno Approvers 144 designated for the Decision 100, the Data 101 object'sstate transits 251 to Data Release Pending 246 state. When there is atleast one Approver 144 designated for said Decision 100, the approvalreview results are evaluated. If all required approvals are “granted,”the Data 101 object's state transits 250 to Data Release Pending 246state. If any approval is “denied”, the Data 101 object's state transits247 to Historical 249 state.

When a Data 101 object's “hold/release” attribute is set to “release”and it is in Data Release Pending 246 state, the Data 101 objecttransits 252 to Standby 253 state and sends “active” to its Arc EntryCollection 134. The “hold/release” attribute can be used to selectivelyretard a project's progress by toggling it to “hold” on selected Data101 objects. When every Decision 100 object belonging to a Project 127has an instantiated Data 101 object which is in state Standby 253, theProject 127 is complete and all Data 101 objects transit 254 toOperational 255 state. When Data 101 objects in Operational 255 stateare superseded by a Data 101 object from a subsequent Project 127, theformer Data 101 object transits 256 to Historical 249 state. The statesInspection or Approval 245, Data Release Pending 246, and Standby 253aggregate to state InProcess 257.

If a Project 127 iterates across Decision 100 objects with related Data101 objects that are in InProcess 257 state, such Data 101 objectstransit 260 to Historical 249 state. If a Project 127 iterates acrossDecision 100 objects with related Data 101 objects in Entry Pending 241state, those Data 101 objects transit 261 out of existence.

If a Project 127 is aborted with Data 101 objects in InProcess 257state, such Data 101 objects transit 258 to Historical 249 state. If aProject 127 aborts with Data 101 objects in Entry Pending 241 state,those Data 101 objects transit 259 out of existence.

Dynamic Behavior of Directed Arc 107 Object. The objects of the DirectedArc 107 class, are the central controlling actors of the “molecular”,inter-decision process. FIG. 13 depicts the dynamic behavior of DirectedArc 107 objects. Upon instantiation 370, each Directed Arc 107 objectenters Dormant 371 state, notifying its related 135 Arc Exit Collection136 of its state. When notified by its Arc Entry Collection 134 objectthat said collection has become active, a Directed Arc 107 objecttransits 372 to Active 373 state and, upon entering that state, notifiesits related 135 Arc Exit Collection 136 of its new state. If, while inActive 373 state, the related Project 127 iterates over the relatedDecision 100 object, the Directed Arc 107 object transits 374 to Dormant371 state, and upon entering that state, notifies its related 135 ArcExit Collection 136 object of its new state. If the Project 127 to whicha Directed Arc 107 object belongs aborts, the Directed Arc 107 objecttransits 375 or 376 out of existence from either Dormant 371 or Active373 state respectively.

Dynamic Behavior of Arc Entry Collection 134 Object. The dynamicbehavior of the Arc Entry Collection 134 objects is depicted in FIG. 14.Upon instantiation 380 an Arc Entry Collection 134 object enters Dormant381 state and sends a message to its member 133 Directed Arc 107 objectscontaining its state. When notified by the Data 101 object produced by102 the Decision 100 associated with its entry 109, that data release252 has occurred, the Arc Entry Collection 134 object transits 382 toActive 383 state and sends it's new state to its member 133 DirectedArcs 107. If, while in Active 383 state, the related Project 127iterates over the related Decision 100 object, the Arc Entry Collection134 object transits 384 to Dormant 381 state, and upon entering thatstate, sends it's new state to its member 133 Directed Arcs 107. If theProject 127 to which a member 133 Directed Arc 107 object belongsaborts, the Arc Entry Collection 134 object transits 385 or 386 out ofexistence from either Dormant 381 or Active 383 state respectively.

Dynamic Behavior of Arc Exit Collection 136 object. The dynamic behaviorof the Arc Exit Collection 136 objects is depicted in FIG. 15. Uponinstantiation 390 an Arc Exit Collection 136 object enters Dormant 391state and sends a message containing its state to the requiring 105Decision 100 object associated with its member 135 Directed Arc 107object's exit 108. When all of its member 135 Directed Arcs 107 are inActive 373 state, the Arc Exit Collection 136 object transits 392 toActive 393 state and sends it's new state to the requiring 105 Decision100 object associated with its member 135 Directed Arc 107 object's exit108. If, while in Active 393 state, the related Project 127 iteratesover the related Decision 100 object, the Arc Exit Collection 136 objecttransits 394 to Dormant 391 state, and upon entering that state, sendsit's new state to the requiring 105 Decision 100 object associated withits member 135 Directed Arc 107 object's exit 108. If the Project 127 towhich a member 135 Directed Arc 107 object belongs aborts, the Arc ExitCollection 136 object transits 395 or 396 out of existence from eitherDormant 391 or Active 393 state respectively.

Dynamic Behavior of Decision Manager 142 Decision Role 121 object. Asdepicted in FIG. 16, the Decision Manager 142 object is instantiated 265in the Prepare Consultation 266 state. If there are no Consultees 143designated for the related Decision 100 object the Decision Manager 142object immediately transits 268 to Deliberation 270 state. Otherwise,the Decision Manager 142 object transits 267 to Consultation 269 whenthe incumbent in the Decision Manager role indicates the beginning ofconsultation. The Decision Manager 142 object transits 271 toDeliberation 270 when the incumbent in the Decision Manager roleindicates the end of consultation. The Decision Manager 142 objecttransits 271 from Deliberation 270 to Standby 272 state when theDecision Manager incumbent enters the decision result. From Standby 272state the Decision Manager 142 object either transits 273 or transits274 upon inspection fail to either Prepare Consultation 266 state orDeliberation 270 state depending, respectively or whether the Decision100 object does or does not have any Consultees 143 designated. Uponapproval deny the Decision Manager 142 object either transits 275 ortransits 276 from Standby 272 state to either Prepare Consultation 266state or Deliberation 270 state depending, respectively or whether theDecision 100 object does or does not have any Consultees 143 designated.States Prepare Consultation 266, Consultation 269, Deliberation 270, andStandby 272 aggregate to state InProcess 277. If the Decision 100 objectto which the Decision Manager 142 object is related iterates, theDecision Manager 142 object transits 278 from state InProcess 277 tostate Dormant 279. If the Project 127 object of which the DecisionManager 142 object is a component aborts, the Decision Manager 142object either transits 283 from state InProcess 277 out of existence ortransits 282 from state Dormant 279 out of existence. Upon Project 127completion the Decision Manager 142 object either transits 284 out ofexistence.

Dynamic Behavior of Consultee 143 Decision Role 121 Object. As depictedin FIG. 17 the Consultee 143 object is instantiated 290 in Dormant 291state. Upon the start of consultation it transits 292 to Consultation293 state. When end consultation occurs the Consultee 143 objecttransits 294 to Standby 295 state. If any related inspection fails, orapproval is denied, or the related Decision 100 object is iterated, theConsultee 143 object returns 296, 297, or 298 respectively to Dormant291 state. The three states of the Consultee 143 object aggregate toInProcess 301 state. If the Project 127 object of which the Consultee143 object is a component, aborts, the Consultee 143 object transits 302out of existence. Upon completion of the project, the Consultee 143object transits 300 out of existence.

Dynamic Behavior of Inspector 145 Decision Role 121 Object. As depictedin FIG. 18 the Inspector 145 object is instantiated 310 in Dormant 311state. Upon decision entry it transits 312 to Inspection 313 state. Ifall inspections pass the Inspector 145 object transits 315 to Standby316 state. If any inspection fails,or the related Decision 100 object isiterated, the Inspector 145 object returns 314 or 317 respectively toDormant 311 state. If the related Decision 100 iterates while theInspector 145 object is in Standby 316 state, the Inspector 145 objecttransits 318 to Dormant 311 state. The three states of the Inspector 145object aggregate to InProcess 320 state. If the Project 127 object ofwhich the Inspector 145 object is a component, aborts, the Inspector 145object transits 321 out of existence. Upon completion of the project,the Inspector 145 object transits 319 out of existence.

Dynamic Behavior of Approver 144 Decision Role 121 Object. As depictedin FIG. 19 the Approver 144 object is instantiated 330 in Dormant 331state. Upon decision entry it transits 332 to Approval 334 state,provided that there are no Inspector 145 objects related to thisDecision 100 object. If there are Inspector 145 objects related to thisDecision 100, the Approver 144 object transits 333 to Approval 334 stateupon all inspections being passed. If all approvals are granted theApprover 144 object transits 336 to Standby 337 state. If any approvalis denied, or the related Decision 100 object is iterated, the Approver144 object returns 335 or 338 respectively to Dormant 331 state. If therelated Decision 100 iterates while the Approver 144 object is inStandby 337 state, the Approver 144 object transits 339 to Dormant 311state. The three states of the Approver 144 object aggregate toInProcess 341 state. If the Project 127 object of which the Approver 144object is a component, aborts, the Approver 144 object transits 342 outof existence. Upon completion of the project, the Approver 144 objecttransits 340 out of existence.

Dynamic Behavior of Informee 146 Decision Role 121 Object. AlthoughInformees are required to act on the information they receive, they areoften playing some other Decision Role 121 in a subsequent Decisions 100which require 103 the Data 104 of the producing 110 Decision 100 and aretherefore Informees 146 of producing 103 Decision 100 they do not needto be modeled as Informees 146 because the inter-decision modelstructure handles their notification. If, however, an Informee's 146need is associated with a Decision 100 that is beyond the model scope(i.e., is either unknown to the subject model or is undefined), messages(e.g., E-mail, office mail) must be sent to the Informee's 146 addressof record. That is the function of the Informee 146 object. FIG. 20depicts the dynamic behavior of the Informee 146 object. Uponinstantiation 350 the object enters Dormant 351 state. Upon data releasethe Informee object 146 transits 352 to Standby 353 state and sends amessage to the role incumbent containing the Data 101 and the state(i.e., released but not yet operational). If the Project 127 iteratesacross the Decision 100 while an Informee 146 object of that Decision100 is in Standby 353 state, the Informee 146 object transits 354 toDormant 351 state and sends a message to the Informee 146 role incumbentindicating the change to Dormant 351 state. If the Project 127 abortswhile an Informee 146 object of a Decision 100 is in Standby 353 stateor Dormant 351 state, the Informee 146 object transits 356 or 357respectively out of existence and sends a message to the Informee 146role incumbent indicating the change. If the Project 127 completes whilean Informee 146 object of a Decision 100 is in Standby 353 state, theInformee 146 object transits 355 out of existence and sends a message tothe Informee 146 role incumbent indicating the change.

Table B indicates the concurrent states of the principal objects of themodel (State=“None” before instantiation and after destruction of anobject. State=“Dormant” after instantiation but before first use of anobject. State=“Standby” pending possible need to iterate project priorto completion.). The vertical dimension is time, but is not to scale.Therefore the length of overlap is not significant. For example, theDirected Arc with an exit related to the decision will be active beforethe Decision can transit from “Dormant” to “Decision Release Pending” asindicated by the overlap of the Directed Arc's Active area and theDecision's Dormant area. However, the time of that overlap may beextremely short for some decisions and relatively long for others.States may be skipped or iterated (see the State Diagrams). Anyhorizontal line will cross possible concurrent states. Where ahorizontal line can be drawn from a state on one object to multiplestates of another object (e.g., Active state of Directed Arc (entry) toDormant and Decision Release Pending states of Decision) all of thecombinations are possible.

Functional Model

Project Instantiation. When a Project 127 is instantiated 128, otherobjects are also instantiated as follows. Referring to FIG. 21, theProject Manager 700 identifies the concrete sub-class of the abstractDecision 100 class from which the initial decision 701 is to beinstantiated. The initial decision 701 class is used to select 702 therequired decision classes 703 and directed arc classes 704 from theProcess 705 object. The selected classes are used to instantiate aProject 706 object and then to instantiate, as components of the Project706 object, an instance of the identified Decision 100 sub-classtogether with an instance of every Decision 707 and Directed Arc 708that is directly or indirectly dependent on the initial decision 701.Instances of all the required Arc Exit Collection 709 objects and ArcEntry Collection 710 objects are also created within the Project 706object.

Decision Role Instantiation. As depicted in FIG. 22, a Decision 720object uses its decision 721 identification to select 722 the requireddecision role classes 723 and positions 724 from the Process 725 object.These are used to create an instance of each required Decision Role 726participant as components of the Project 727 object.

Data Instantiation. FIG. 23 depicts the instantiation of Data objects. ADecision 730 object provides its decision 731 identification which areused to select 734 the appropriate data class 735 from the Process 736object. The Decision 730 object also furnishes the value of its datahold/release 732 attribute which is used to instantiate the Data 737object with the hold/release value and state, as a component of theProject 738 object.

Project Iteration. During the course of a project, it may becomenecessary to revisit a decision that has already has already been made,inspected, approved and its released for use in other project decisions.Any decision instance that is in a non-dormant state is a potentialcandidate for iteration. When a decision is iterated the result maychange and therefore, all decisions that use that result must also beiterated. Hence, decision iteration usually entails iteration of thatportion of the project that is both active and “downstream” from thedecision to be iterated. FIG. 24 depicts the functional model of projectiteration. The Project Manager 750 identifies the decision to beiterated 751. The fist step 752 is to send a “pause” 753 message to theProject 754 object. Then The decisions 755 and directed arcs 756 areretrieved from the Project 754 object and those that are dependent onthe decision to be iterated are selected. The state 759 of each of thepreviously selected decisions is retrieved from the Decision 758 objectsand those which are in non-dormant state selected 760. Theidentification of the selected decisions 763 together with the “iterate”764 message is sent to the Decision 758, Data 765 and Decision Role 766objects. Finally, the project is resumed 767 by sending a “resume” 768message to the Project 754 object.

While the present invention has been described with reference to a fewspecific embodiments, the description is llustrative of the inventionand is not to be construed as limiting the invention. Variousmodifications may occur to those skilled in the art without departingfrom the spirit and scope of the invention as defined in the appendedclaims. For example, it would be natural to make the “data hold/release”toggle an attribute of the Data 101 object. However, the preferredembodiment defers the instantiation of Data 101 objects until they arerequired for entry of the Decision 100 result. It is desirable to beable to specify a hold on the release of the decision result at the timethe Project 127 object is created. There are a variety of ways that thismight be accomplished. The Data 101 object could be instantiated atProject 127 inception or all “data hold/release” attributes might beplaced in an object instantiated for this purpose at Project 127inception and pass them to Data 101 objects when the latter areinstantiated. The preferred embodiment is to carry the “data hold”attribute value in the Decision 100 object, which is instantiated atProject 127 inception and pass it to the Data 101 object as the latteris instantiated.

A further example is the time chosen to instantiate the Inspector 145and Approver 144 objects. Our preferred implementation instantiates themat the same time as the other Decision Role 121 objects on theexpectation that there will be relatively few of them and that the modelof their classes and relationships in the Process 129 model will berelatively stable. They could be implemented with a later instantiation,which would be preferred under circumstances other than thoseanticipated.

Nor are all the features of the implementation described here essentialto the novelty or usefulness of the invention. For example, the abilityto place holds selectively on the release of either decisions or theirresults is a feature that will probably be valued but need not be a partof the implementation. Similarly, the distinction made between theInspector 145 and Approver 144 roles adds utility, but is not essentialto the invention. These details of implementation are presented fortheir illustrative value and may be altered to accommodate theparticular trade-offs of a specific application situation. They do nothave any bearing on the scope or novelty of the present invention.

1-55. (canceled)
 56. A method for managing one or more work processescomprising: constructing a computer-based process model of a workprocess, where the computer-based process model includes two modeledroles for persons participating in a modeled task of the work process;specifying role behaviors for the two modeled roles, where specificationof the role behaviors is without reference to a specific task of thework process; and using the computer-based process model to support atleast one of execution, control, and improvement of the work process.57. The method of claim 56, wherein: the modeled task is a decisionrequiring choice from among alternatives; and the role behaviors for afirst modeled role include a right of a first person participating inthe first modeled role to make the decision.
 58. The method of claim 57,wherein the role behaviors for a second modeled role include a right ofa second person participating in the second modeled role to veto thedecision.
 59. The method of claim 57, wherein the role behaviors for asecond modeled role include a right of a second person participating inthe second modeled role to an opportunity to influence the decision. 60.A method for managing one or more work processes comprising:constructing a computer-based process model of a work process, where thecomputer-based process model includes two instances of a task model,where each instance of the task model models a task that is aconstituent of the work process; providing a structure associated withthe task model that defines, without reference to a particular task,differentiated roles for persons participating in a task modeled by thetask model; and using the computer-based process model to support atleast one of execution, control and improvement of the work process. 61.The method of claim 60, wherein interactions among persons participatingin a task modeled by an instance of the task model are defined by thestructure associated with the task model that defines, without referenceto a particular task, differentiated roles for persons participating ina task modeled by the task model.
 62. The method of claim 61, whereinany modeled requirement that a first instance of the task model whichmodels a first task be executed before a second instance of the taskmodel which models a second task, results from a requirement by thesecond task for a result of the first task.
 63. The method of claim 62,wherein the result of the first task, required by the second task, maybe required for any one or more of (1) determining a requirement by thesecond task for a result of a third task, (2) determining a requirementfor a person to participate in the second task, (3) determining a taskrole of a person participating in the second task, and (4) determining aresult of the second task.
 64. A method for managing one or more workprocesses comprising: providing a computer-based software frameworkconsisting of related software classes and software objects including anabstract task class, where a constituent task of a work process ismodeled by a class derived from the abstract task class; and includingconcrete role classes associated either with the abstract task class orwith a class derived from the abstract task class, where the concreterole classes model roles of persons participating in a task modeledeither by the abstract task class or by the class derived from theabstract task class with which the concrete role classes are associated;using the computer-based software framework to construct acomputer-based process model of the work process; and using thecomputer-based process model to support at least one of execution,control and improvement of the work process.
 65. The method of claim 64,wherein: the task modeled either by the abstract task class or by theclass derived from the abstract task class, is a decision, requiringchoice from among alternatives; and a first concrete role class models afirst role, where anyone participating in the first role modeled by thefirst concrete role class has a right to make a decision modeled by anassociated task class.
 66. The method of claim 65, wherein a secondconcrete role class models a second role, where anyone participating inthe second role modeled by the second concrete role class has a right toveto a decision modeled by an associated task class.
 67. The method ofclaim 65, wherein a second concrete role class models a second role,where anyone participating in the second role modeled by the secondconcrete role class has a right to an opportunity to influence adecision modeled by an associated task class.